In a database management system (DBMS), data is stored in one or more data containers. Each container contains records. The data within each record is organized into one or more fields. In relational database management systems, the data containers are referred to as tables, the records are referred to as rows, and the fields are referred to as columns. In object-oriented databases, the data containers are referred to as object classes, the records are referred to as objects, and the fields are referred to as attributes. Other database architectures may use other terminology.
Database management systems retrieve information in response to receiving queries that specify the information to retrieve. In order for a database management system to understand the query, the query should conform to a database language recognized by the database management system, such as the Structured Query Language (SQL).
A transaction is a logical unit of work that is atomic and comprised of one or more database language statements. In a database server, an area of system memory is allocated and one or more processes are started to execute one or more transactions. The database server communicates with connected user processes and performs tasks on behalf of the user. These tasks typically include the execution of transactions. The combination of the allocated system memory and the processes executing transactions is commonly termed a database instance.
A session is a specific connection of a user to a database server via a user process. For example, when a user starts a database application, the user typically provides a valid username and password. The username and password are sent from the database application to the database server. The database server establishes a session for the user in response to receiving the username and password. The session lasts from the time the user connects to the database server until the time the user disconnects from the database server (or exits the database application).
Large business-critical applications are complex and experience highly varying load and usage patterns. These applications are expected to provide certain service guarantees in terms of response time, throughput, uptime, and availability. At times, it may be desirable to change a system that includes such applications. Such a change might involve upgrading the system's database or modifying a configuration, for example. However, before any change is made to a production system, extensive testing and validation should be performed in a test system. In order to be confident that a change will not cause problems (e.g., errors or performance issues) in the production system once that change is introduced into the production system, a system tester should try to expose the test system to a workload that is very similar to the workload that the production system would actually experience in a real world environment.
U.S. patent application Ser. No. 11/800,122 describes how a test database system (referred to herein as the “test system”) may be subjected to the same workload to which a production database system (referred to herein as the “production system”) would be subjected. To subject the test system to the same workload to which the production system would be subjected, a database server in the production system (a “production database server”) captures and records workload that the production database server receives from external entities. This captured workload is then processed by the test relational database system, potentially in a non-real-time, out-of-line manner. One or more processes external to a database server in the test system (a “test database server”) send the processed workload to the test database server. The test database server executes the workload. As a result, the test system is subjected to the same workload to which the production system was originally subjected.
It can be beneficial to replay, on the test system, the entire workload that was captured on the production system. However, under some circumstances, a user might want to replay only a portion of the captured workload on the test system.
A multitude of various environmental variables may be established during a session in the production system. These variables make up the session's state. A session's state may and often does change during the course of the session. A session's current state can and often does affect the results of the operations that are performed in that session. The operations that are performed in a session also can and often do affect the session's state. If an attempt were made to replay captured workload in a session that had a different session state than the session in which the workload was originally captured, then unexpected results could occur.